…g types

Prepares the type surface for the watchdog-reclaim and conflict-aware
accounting that follow in subsequent commits. The three existing
SyncResult return sites in base-queue.ts also gain conflicted: 0 so
type-check stays green per commit; actual conflict counting lands when
the per-item branching is added.

void return from processItem remains valid for backward compatibility.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

A tab that crashes after atomically claiming a queue item but before
writing the completion update leaves the row in 'processing' forever.
The claim guard requires status === 'pending', so no other tab will
ever re-claim it. The watchdog runs at the top of sync() and resets
'processing' items older than processingTimeoutMs (default 60s) back
to 'pending'. processItem MUST be idempotent for safe reclaim — that
side of the contract is enforced for payment_intents in a follow-up
commit (idempotency_key partial unique index).

Two regression cases pin the contract:
- Reclaim: 70s-old processing row is recovered and processed.
- Negative: 30s-old processing row is left alone.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

processItem may now return { status: 'conflicted' } to signal that the
work was already done server-side (typical case: an idempotency-key
INSERT that hit ON CONFLICT DO NOTHING). The queue row still marks
completed, but SyncResult tracks the dedupe count separately for
observability. void return remains valid and is treated as
{ status: 'completed' } so existing subclasses don't break.

The abstract processItem signature now accepts ProcessItemResult | void,
so payment-adapter (next commit) can return the discriminator.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Stable key per logical payment intent. Retries of a queued payment
INSERT now share the same key, so server-side ON CONFLICT DO NOTHING
makes them no-ops instead of duplicates. The actual upsert switch lands
in the next commit; this one just establishes the data flow.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ine retry safety

Replaces the prior insert() with upsert(..., { onConflict:
'idempotency_key', ignoreDuplicates: true }), which maps to INSERT ...
ON CONFLICT DO NOTHING server-side. A queued retry whose prior attempt
already created the row now returns zero rows; the adapter signals
{ status: 'conflicted' } and the queue row marks completed without
double-charging.

Older queued items (queued before the idempotency_key column shipped)
fall back to generating a fresh key inside executePaymentIntent and
log a warning. That retry chain will dedupe with itself; prior attempts
that ran without a key cannot dedupe against it. Acceptable for a
24-hour-expiry table.

subscription_update keeps void return — UPDATE is implicitly idempotent
by primary key, no dedupe distinction needed.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…acts

Two regression cases for the #52 retry-safety surface:
1. Queued idempotency_key flows into the upsert payload with the
   correct onConflict + ignoreDuplicates options.
2. A zero-row upsert response is treated as conflicted (the prior
   attempt's row is already there); the queue row still completes,
   but result.conflicted increments instead of result.success.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Captures the design rationale (why watchdog + idempotency must land
together) and the bite-sized task plan that produced the preceding
runtime commits. Future readers can reconstruct the decision boundary
without re-deriving it from PR descriptions.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>